A major reason for the high cost of conventional state-of-the-art ATE test systems is the specialized and complex nature of the ATE tester architecture. ATE tester manufacturers typically employ a number of ATE tester platforms that are not only incompatible across companies, but also incompatible across platforms. Because of these incompatibilities, each ATE tester may require its own specialized hardware modules and software components that cannot be used on other ATE testers. This specialized hardware and software is expensive to develop and time-consuming and difficult to utilize. A steep learning curve is often required for those who assemble, program and operate such testers.
Because of the dedicated nature of conventional ATE tester architecture, all hardware and software must remain in a fixed configuration for a given ATE tester. To test an IC, a dedicated global test system program is developed that uses some or all of the ATE tester capabilities to define the test data, signals, waveforms, and current and voltage levels, as well as to collect the Device Under Test (DUT) response and determine DUT pass/fail. The specialized nature of ATE test systems lends itself to production-scale testing of large quantities of DUTs to ensure they pass all tests and are suitable for release into the stream of commerce. In such an environment, the same ATE test system and test software is used repeatedly to test each DUT.
Conversely, ATE test systems are not particularly well-suited for testing and verification of prototype devices, which may contain design or manufacturing errors or other “bugs.” As mentioned above, the cost of developing specialized modules to test prototypes may be prohibitive. Moreover, the test software itself may contain errors, and the complexity of ATE test systems and the specialized nature of the ATE tester software may make it difficult to debug and modify the global test system program. ATE systems are even more ill-suited for the laboratory environment benchtop testing of “proof-of-concept” breadboards and other early-stage hardware designs, where low cost and ease of use are imperative for the test equipment.
To increase the flexibility, applicability, and to lower the cost of test systems, it would be desirable to utilize a standardized test architecture and tester software so that an ATE system could use pre-fabricated instrument cards and device driver software from third-party manufacturers, rather than design hardware modules and local test program software from scratch. The standardized architecture and tester software would also allow a test engineer to quickly make changes to the hardware and software, as needed, during pre-production testing of a device.
For example, PXI is a standardized system of electronic instruments comprised of a specified enclosure, a specified backplane and bus architecture, and plug-in cards that implement various types of instruments. PXI is a rugged Personal Computer (PC)-based platform for measurement and automation systems that combines PCI electrical-bus features with the rugged, modular, Eurocard mechanical-packaging of compactPCI (cPCI), then adds specialized synchronization buses and key software features. Further details on PXI may be found in “PXI™ Hardware Specification,” Revision 2.2, Sep. 22, 2004, by PXI Systems Alliance, available online at www.pxisa.org, the contents of which are incorporated by reference herein.
FIG. 1 is an illustration of an exemplary PXI system 100 and some of the backplane bus signals provided by PXI. The PXI system 100 includes a chassis, backplane, and slots for cards or modules. Note that the PXI system 100 is controlled by a controller (not shown in FIG. 1) executing a global test system program that may be located in one of the slots in the PXI system or external to the PXI system 100 (e.g. a PC). At least one of the cards in the PXI system is a star trigger card 110, which serves as a local controller for the PXI chassis and is the central point for signals being sent to, or received from, the other cards or modules.
In the example of FIG. 1, one or more PXI cards or modules 102 and one or more star trigger cards 110 within a particular segment 104 are connected in parallel to a cPCI bus 106 and a trigger bus PXI_TRIG 108, which is shown in FIG. 1 as having eight lines PXI_TRIG[7:0] but may comprise a different number of lines. The cPCI bus 106, which is based on the cPCI specification, provides an interface between a test controller or personal computer (not shown in FIG. 1) and the star trigger card 110 and pincards or modules 102 for configuration purposes by allowing the test controller to talk to individual modules. In addition, PXI cards or modules 102 and star trigger cards 110 across all segments receive a 10 MHz reference clock PXI_CLK10 116 synchronized through the backplane to within a small delay (e.g. 1-2 ns). The cPCI bus 106 and the PXI_CLK10 116 are specified by the cPCI standard. A bridge 118 may be employed to extend signals such as the cPCI bus 106 to other segments or chassis.
To facilitate communications between modules beyond what cPCI provides, PXI provides a trigger bus PXI_TRIG 108 that is defined as a standard connection between modules. That is, any module can drive PXI_TRIG 108 and any module connected to PXI_TRIG 108 can receive signaling on PXI_TRIG 108. The PXI_TRIG 108 in FIG. 1 is illustrated as having eight lines PXI_TRIG[7:0], but in other embodiments may contain a different number of lines. Because of load limitations within PXI, which limit certain drivers to only 10 loads or modules, PXI_TRIG 108 within a PXI chassis may be segregated into different segments. PXI_TRIG 108 connects to all modules within a segment, but cannot connect to modules in other segments unless a bridge is used.
PXI also extends cPCI by daisy-chaining the star trigger card 110 and the pincards or modules 102 together using a local bus PXI_LOCAL 112 that connects to left (L) and right (R) connectors on each PXI module 102 or star trigger card 110. PXI_LOCAL 112 in FIG. 1 is illustrated as having 12 lines PXI_LOCAL[11:0], but in other embodiments may contain a different number of lines. PXI has left the specification for the local bus open and definable by the modules, so that a module or test system developer can utilize the local bus for any purpose.
In addition, the star trigger card 110 is connected to each slot in the PXI chassis across all segments through a point-to-point PXI_STAR bus 114, which is shown in FIG. 1 as having 13 lines [12:0] but may comprise a different number of lines. The PXI_STAR bus 114 allows the star trigger card 110 to start multiple modules at the same time.
The cPCI bus, PXI_CLK10, PXI_LOCAL and PXI_STAR do not have fanout limitations, and therefore can connect to all modules in all segments within a PXI chassis.
FIG. 2 shows an example of a PXI card cage or enclosure 200, and FIG. 3 shows an example of a PXI card 300. Many companies produce a large variety of PXI instruments that perform specific functions, including programmable power supplies, Arbitrary Waveform Generators (AWGs), DiGiTizers (DGTs) and Radio Frequency (RF) signal generators. PXI instruments are typically used as benchtop test equipment, or as small functional test systems. Connections from the PXI card to an external device are generally through front panel cable connections, via BNC, SMA, SMB, or other connectors determined by the PXI card designer. PXI cards usually come with software drivers for Windows®, LabView®, and the like.
Because there are many existing PXI instrument cards, use of these instrument cards as part of an ATE test system could drastically cut development time as compared to developing the same instrument from scratch. Also, when the expected production quantity of a given test system module is small, utilizing off-the-shelf instrument cards within an ATE test system can be more economical than developing a new module. Furthermore, the standardized PXI architecture and global test system software enables a test engineer to quickly make changes to the hardware and software, as needed, during pre-production testing of a device.
However, because PXI was not developed to generate the precise timing control required for state-of-the-art ATE test systems, heretofore it has been impossible to utilize PXI in sophisticated ATE test systems. Therefore, there is a need to provide precise timing control within a standardized test instrumentation chassis such as PXI so that an ATE test system with all the attendant benefits of a standardized test instrumentation system can be realized. Because the number of cards in a standardized test instrumentation chassis is fixed, there is a further need to provide precise timing control across multiple standardized test instrumentation chassis.
In particular, there is a need to have all modules in the test system start at the same time, which PXI_STAR can provide in PXI. However, PXI_STAR is limited to a fixed number of modules (e.g. 13 modules), depending on the design of the star trigger card and the backplane. If a test system with more than 13 synchronous modules is desired, then something besides PXI_STAR must be used. A second need stems from the fact that although PXI provides PXI_CLK10, test system modules may operate at faster clock frequencies generated within the modules such as 20.833 MHz, 125 MHz, and the like. The modules cannot be started at the same time if these clocks are not in synchronization with each other. Thus, there is a need to synchronize clocks generated within the modules.
A third need is driven by that fact that a PXI chassis can only hold a certain number of modules, yet some test systems will require a greater number of modules than one chassis can hold. Multiple PXI chassis may therefore be needed to hold all of the modules in a test system. PXI is capable of addressing modules across chassis. In addition, a limited multi-chassis synchronization capability exists within PXI, through a bridge constrained to the cPCI protocol. This cPCI bridge allows PCI communications between modules in different chassis. However, PXI has no provision for connecting the other signals (PXI_CLK10, PXI_TRIG, PXI_LOCAL and PXI_STAR) to multiple chassis. Therefore, there is no mechanism in PXI to allow modules to start at the same time or generate fast clocks in synchronization across chassis. This creates a need to synchronize clocks and modules across multiple PXI chassis.
In ATE test systems, each pin on each module or pincard may contain an Application Specific Integrated Circuit (ASIC), memory such as Random Access Memory (RAM), and other pin electronics, and may execute a local test program to generate vectors for a DUT input pin. The basic configuration, synchronization and starting of pins and modules within a chassis is controlled by global test system software being executed in a controller, but in per-pin testers, each pincard or module executes its own local test program.
The local test program for each pin must be precisely started or stopped in order for the overall test system to operate properly. In addition to start and stop operations, there are operations to loop around within the local test program. For example, when executing a local test program, at a certain vector the local test program may need to check for certain conditions (i.e. look for a certain output on a DUT output pin) and, based on this check, decide whether to continue (if the expected conditions are observed) or loop back and repeat a portion of the local test program (if the expected conditions are not observed). This loop-back capability is frequently needed for Phase-Locked Loops (PLLs), where the PLL must have stabilized before further testing can begin. For example, other modules may have to loop-back and repeat sections of their local test program while waiting for the PLL to stabilize. In other test systems, a proprietary connection is used for this purpose. However, PXI does not provide for a loop-back capability in which modules in the test system can simultaneously determine that loop-back is required. Therefore, a mechanism is needed within the confines of PXI to indicate to the modules to either loop-back and repeat sections of their local test programs, or continue with their local test program.